Set transport param in the Contact header for SIP Request

[Moloy]

Hello,

We are trying to set TransportParam in the Contact header as "Contact:
<sip:128.107.140.14:5060;transport=tcp;app-session-id=c1de0e16>" for
SIP Request. When we create Request object we set this, but in
org.cipango.server.session.Session.customizeRequest() ContactUri is
updated based on the ConnectorUri information. If ConnectorUri did not
had a TransportParam, it removes the TransportParam from ContactUri.

SipURI uri = connection.getConnector().getSipUri();
Address contact =
request.getFields().getAddress(SipHeaders.CONTACT_BUFFER);
SipURI contactUri = (SipURI) contact.getURI();
contactUri.setHost(uri.getHost());
contactUri.setPort(uri.getPort());
if (uri.getTransportParam() != null) {
contactUri.setTransportParam(uri.getTransportParam());
} else {
contactUri.removeParameter(SipURIImpl.TRANSPORT_PARAM);
}

I was going through the SipConnector and did not find any code setting
the the TransportParam for SipUri in SipConnector. What should be the
right way to set transport param in the Contact header for Request.

Thanks in advance.
Moloy

[Thomas]

Hello Moloy,

Do you send the request with this Contact header using TCP ? Or do you want to include transport=tcp in a request sent with UDP ?

Regards,

Thomas

> --
> You received this message because you are subscribed to the Google Groups "cipango-users" group.
> To post to this group, send email to cipang...@googlegroups.com.
> To unsubscribe from this group, send email to cipango-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cipango-users?hl=en.
>

[Thomas]

Hi Neil,

I get your point. Indeed, cipango had this behavior a few versions ago but we had interoperability issues with some equipments. Transport parameter in URI such as Contact and Record-Route seems to be a topic with various interpretations and we still have to find a universal solution to it. By the way, I may have missed updates on this and if you have links to discussions or standards stating what should/shall be done, we'll be happy to integrate them (RFC 5658 provides hints for Record-Route but it is less clear for Contact).
Anyway, I would propose to add a setTransportParameter method on the connectors so that you may indicate in cipango configuration that you would like a particular connector to include a transport parameter in its URI. Would it be ok for you ?

Regards,

Thomas

Le 9 févr. 2012 à 16:50, nejoshi a écrit :

> Hi Thomas,
>
> Yes, we send this request over TCP. The b2bua we are using requires us to
> include transport= in the Contact header.
>
> Is there a way to have cipango set this field automatically based on what
> transport protocol we are using? Currently, we are adding it manually after
> creating a request or response like this:
>
> TRANSPORT_PARAM_KEY = "transport";
> Address address = response.getAddressHeader(SipHeaders.CONTACT);
> if (Util.notNull(address) && Util.notNull(address.getURI())) {
> address.getURI().setParameter(TRANSPORT_PARAM_KEY, TCP);
> }
>
> This works for responses, but not for request (as Moloy described below).
>
> Thanks for your help.
>
> Neil

[Thomas]

Hi Neil,

I think that an UAC application (i.e. the servlet) should be notified of 491 responses. 3261 reads that the UAC should retransmit the INVITE at a later stage but the UAC may decide not to do so and SIP Servlets should offer all the flexibility to SIP applications.
From a SIP standpoint, nothing prevents 491 handling to be in the application since the retransmitted invite is a new one and starts a new transaction.

As a result, 491 have no dedicated processing in cipango UAC. But I agree that it may be added as a helper feature (in an application framework or an optional container feature), we'll add it on our backlog.

Regards,

Thomas

Le 9 févr. 2012 à 18:55, nejoshi a écrit :

> Thanks Thomas, that would be great. Also, I will look for any documentation
> that might clarify proper usage of the transport parameter.
>
> I hope I'm not violating the mailing list's etiquette, but I have one more
> question to ask not related to the current discussion. If it is not
> appropriate, I can resend under a new heading.
>
> What is cipango's current support for 491 Request Pending. The RFC specifies
> that if a UA receives a 491, it will back-off and resend the request. I saw
> recently, cipango propagates 491 responses to the application like all other
> errors. Is the intent for the application to handle the retransmit or can
> cipango handle this as a future enhancement.
>
> Thanks again for the assistance.
>
> Neil

[Thomas]

Hi Neil, 

We've just committed a change which allows to set transport in the connector URI. If set to true, the transport parameter is added by the container. It may be configured in the cipango.xml as follows:

<Call name="addConnector">
      <Arg>
        <New class="org.cipango.server.bio.TcpConnector">
          <Set name="port"><Property default="5060" name="sip.port"/></Set>
          <Set name="host"><Property name="sip.host"/></Set>
          <Set name="transportParam">true</Set>        </New>
      </Arg>
    </Call>

Please let us know whether this fixes your issue. 

[Thomas]

Hi Moloy,

You should build from the source. It is straightforward, please follow instructions at
http://confluence.cipango.org/display/DOC/Installing+Cipango#InstallingCipango-BuildfromSourceCode

If you have any issue when building, please get back to us.

Regards,

Thomas

Le 10 févr. 2012 à 18:33, Moloy a écrit :

> Thanks Thomas. This would help. How do we get this build?
>
> Thanks
> Moloy

[Moloy]

Hi Thomas,
Sounds good! We will add 491 handling in the application.

Appreciate your help.
Moloy

[Moloy]

Hi Thomas,
This would definitely help. How do we get this build?

Thanks
Moloy

On Feb 10, 5:06 am, Thomas <tho...@cipango.org> wrote:

[Moloy]

Hi Thomas,
I did build the cipango-server from trunk and tried, but it did not
help, it did remove the transportparam from contact header. I think
why this is not working is,
In Session.customizeRequest it is getting SipUri from the connector.
To fill contact header it is checking transportparam on the uri, not
on the connector.
Any thought?

Thanks for helping.
Moloy

On Feb 10, 9:38 am, Thomas <tho...@cipango.org> wrote:
> Hi Moloy,
>

> You should build from the source. It is straightforward, please follow instructions athttp://confluence.cipango.org/display/DOC/Installing+Cipango#Installi...

[Thomas]

Moloy,

Did you modify the cipango.xml configuration to enable the feature ?
The customizeRequest should be ok since it copies the connector URI including the transport param in the request Contact header.

Regards,

Thomas

[Moloy]

My bad! after adding that, it works fine. In our system we are using
Cipango 2.1. But I verified this issue with cipango-server 2.2-
SNAPSHOT (rest all the components were still 2.1). Would it be
possible to get a patch that we can apply on top of cipango-server
2.1.

Appreciate your help.
Moloy

[Thomas]

Hi Moloy,

Great, thanks for the feedback ! We've just tagged a 2.1.1 version with this feature.

Regards,

Thomas

[Moloy]

Thanks Much. It works perfectly, appreciate your help.