Contact header in ACK

[breeze]

Hello guys
Could you help, please )

Does cipango process ACK without Contact header? I've two SIP phones.
First one adds Contact, second don't add it.
Callflow with first phone is correct: INVITE - 200 Ok - ACK. But
callflow with second phone is wrong: INVITE - 200 Ok - ACK - 200 Ok -
ACK, etc

The only difference I can find is Contact header in ACK request. Is it
necessary to have it in ACK?

[Thomas]

Hi,

Contact header in ACK is not needed in SIP and therefore not expected by Cipango. There may be another difference. Could you post more message details ? (message.log, pcap dump ...) so that we can have a look ?

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.
>

[Королёв Илья]

Hi, Thomas

Here are two pcap - good and bad.
There are 3 actors:
192.168.2.130 - SIP phone
*.*.64.43 - cipango
*.*.64.109 - another one SIP UA

Cipango acts as a b2bua.

15.07.2011, 16:39, "Thomas" <tho...@cipango.org>:

[Thomas]

The issue comes from your first SIP phone. The transaction id (branch parameter of the Via) of the ACK is similar to the one of the INVITE. Since answer to the INVITE is a 200, the ACK must be sent is in a new (pseudo) transaction and with a branch different from the INVITE one.
If the 192.168.2.130 is a script, it may be a copy-paste issue, if it is a real phone, it looks like a bug.

Regards,

Thomas

> <bad.pcap><good.pcap>

[Ilya Korolev]

Thanks a lot, Thomas!

15.07.2011, 17:40, "Thomas" <tho...@cipango.org>:

[breeze]

There is one more issue, actually.

As you can see in 'good', AS on *.109 doesn't accept ACK from
cipango and send a lot of 200 responses. As for me, problem is in AS -
it requires that whole To header should be the same as in INVITE (not
just tag). I'm not sure that it's correct, but it may be impossible to
change this behaviour.
Could you please suggest a way to do it? Problem is - in INVITE 'To'
header is
'<sip:3...@192.168.64.109:5070>;aai=
\"192.168.64.43-1312d9ceb57-1,s45,parturi\"', but in ACK it's
'conference <sip:confe...@multifon.ru>;tag=...'. Is it possible to
change it in proper way?

> >>>>   For more options, visit this group athttp://groups.google.com/group/cipango-users?hl=en.

> >>>  --
> >>>  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 athttp://groups.google.com/group/cipango-users?hl=en.

> >>  --
> >>  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 athttp://groups.google.com/group/cipango-users?hl=en.

[Thomas]

Indeed, there is an issue with ACK (message 12 in good.pcap). Could you send us the code snippet used to create this ACK ?

Regards,

Thomas

[breeze]

INVITE from client is to 'confe...@multifon.ru'

INVITE from cipango is created by:
B2buaHelper b2b = request.getB2buaHelper();
Address contact = ...;// new Address that will be
'te...@192.168.64.109:5060'
contact.setParameter("aai", ...);
SipURI sipaddr = (SipURI) contact.getURI();
sipaddr.setUser("300");

Map<String, List<String>> headers = new HashMap<String,
List<String>>();
List<String> toHeader = new LinkedList<String>();
toHeader.add(contact.toString());
headers.put("To", toHeader);

// request is SipServletRequest with INVITE from
client
SipServletRequest other = b2b.createRequest(request, true, headers);


ACK is created by:
// origRequest is ACK from client
B2buaHelper b2b = origRequest.getB2buaHelper();
SipSession ss = b2b.getLinkedSession(origRequest.getSession());
SipServletRequest other = b2b.createRequest(ss, origRequest, null);

On Jul 18, 5:15 pm, Thomas <tho...@cipango.org> wrote:
> Indeed, there is an issue with ACK (message 12 in good.pcap). Could you send us the code snippet used to create this ACK ?
>
> Regards,
>
> Thomas
>
> Le 18 juil. 2011 à 14:53, breeze a écrit :
>
>
>
>
>
>
>
> > There is one more issue, actually.
>
> >  As you can see in 'good', AS on *.109 doesn't accept ACK from
> > cipango and send a lot of 200 responses. As for me, problem is in AS -
> > it requires that whole To header should be the same as in INVITE (not
> > just tag). I'm not sure that it's correct, but it may be impossible to
> > change this behaviour.
> >  Could you please suggest a way to do it? Problem is - in INVITE 'To'
> > header is
> > '<sip:3...@192.168.64.109:5070>;aai=
> > \"192.168.64.43-1312d9ceb57-1,s45,parturi\"', but in ACK it's

> > 'conference <sip:confere...@multifon.ru>;tag=...'. Is it possible to

[Thomas]

Ok, I see. There is a missing check and exception in cipango here. You are not allowed to use the createRequest of the B2buahelper to create the ACK (similar to SipSession.createRequest). The reason is that ACK can only be created from the received 200 OK (since the ACK can be considered to be an "answer" to the 200 OK).

You can either send immediately the ACK to the 200 OK (without waiting the ACK from the first leg), save the 200 OK to create the ACK later or use the getPendingMessages to retrieve the 200 OK. Easier method is usually to create the ACK as soon as possible to prevent retransmission (i.e when handling the 200 OK) unless you need information from the first leg.

(I'll also create a JIRA since cipango should have raised an exception in your code).

Regards,

Thomas

[ya-b...@ya.ru]

Thanks for great explanation!
I tried getPendingMessages already, but as far as I remember, 'To' header was 'conference@...' with correct tag. SipSession.getRemote contains 'conference@...' as well. I'll double check it tomorrow.

18.07.11, 17:45, "Thomas" <tho...@cipango.org>:

--
Отправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail

[Thomas]

Yes you're right, we just ran a few tests and it turns out that there is a bug in the b2buahelper as well when To header is in the header map for the initial request.
You have still to change the ACK generation and we also have to fix this bug. We'll address this issue tomorrow.

Regards,

Thomas

[breeze]

Good news )
Do you plan to release a new version or just svn commit? Is svn
stable enought for production?

On Jul 18, 7:13 pm, Thomas <tho...@cipango.org> wrote:
> Yes you're right, we just ran a few tests and it turns out that there is a bug in the b2buahelper as well when To header is in the header map for the initial request.
> You have still to change the ACK generation and we also have to fix this bug. We'll address this issue tomorrow.
>
> Regards,
>
> Thomas
>

> Le 18 juil. 2011 à 16:55, ya-bre...@ya.ru a écrit :
>
>
>
>
>
>
>
> > Thanks for great explanation!
> >  I tried getPendingMessages already, but as far as I remember, 'To' header was 'conference@...' with correct tag. SipSession.getRemote contains 'conference@...' as well. I'll double check it tomorrow.
>
> > 18.07.11, 17:45, "Thomas" <tho...@cipango.org>:
>
> >> Ok, I see. There is a missing check and exception in cipango here. You are not allowed to use the createRequest of the B2buahelper to create the ACK (similar to SipSession.createRequest). The reason is that ACK can only be created from the received 200 OK (since the ACK can be considered to be an "answer" to the 200 OK).
>
> >> You can either send immediately the ACK to the 200 OK (without waiting the ACK from the first leg), save the 200 OK to create the ACK later or use the getPendingMessages to retrieve the 200 OK. Easier method is usually to create the ACK as soon as possible to prevent retransmission (i.e when handling the 200 OK) unless you need information from the first leg.
>
> >> (I'll also create a JIRA since cipango should have raised an exception in your code).
>
> >> Regards,
>
> >> Thomas
>
> >> Le 18 juil. 2011 à 15:25, breeze a écrit :
>

> >>> INVITE from client is to 'confere...@multifon.ru'

>
> >>> INVITE from cipango is created by:
> >>> B2buaHelper b2b = request.getB2buaHelper();
> >>> Address contact = ...;// new Address that will be

> >>> 't...@192.168.64.109:5060'

[Thomas]

We'll commit in SVN this week so that you are able to test. If everything runs fine, we'll prepare a new version quickly afterward.

[Thomas]

Hi,

We've just committed a patch that may solve the To header issue. Could you build from the trunk and check if it helps ?

Regards,

[Ilya Korolev]

Could you please tell, how I can build cipango from sources?
I use instruction from http://confluence.cipango.org/display/CIPANGO10/Building+from+Source but cipango is installing into ~/.m2, not to jetty directory

20.07.2011, 16:48, "Thomas" <tho...@cipango.org>:

[Thomas]

You link refers to cipango 1.0 documentation. The build system is very straightforward now and explained at:
http://confluence.cipango.org/display/DOC/Installing+Cipango#InstallingCipango-BuildfromSourceCode

Regards,

[Ilya Korolev]

I tested fixed version and it works perfectly
Thanks a lot

20.07.2011, 23:15, "Thomas" <tho...@cipango.org>:

[breeze]

Hi

It seems, it will be not easy to fix SIP client to send different
branch in ACK. Is there any possibility to change cipango behaviour -
to let it skip this incorrect branch? May be some config parameter or
smth?

On Jul 21, 2:28 pm, Ilya Korolev <ya-bre...@ya.ru> wrote:
> I tested fixed version and it works perfectly
> Thanks a lot
>
> 20.07.2011, 23:15, "Thomas" <tho...@cipango.org>:
>
>
>
>
>
>
>
> > You link refers to cipango 1.0 documentation. The build system is very straightforward now and explained at:

> >http://confluence.cipango.org/display/DOC/Installing+Cipango#Installi...

>
> > Regards,
>
> > Le 20 juil. 2011 à 20:46, Ilya Korolev a écrit :
>
> >>  Could you please tell, how I can build cipango from sources?

> >>  I use instruction fromhttp://confluence.cipango.org/display/CIPANGO10/Building+from+Sourcebut cipango is installing into ~/.m2, not to jetty directory

> >>>>>>>>>   You...
>
> read more »

[Thomas]

Hi Ilya,

You mean that the UA is sending ACK for 200 OK with the same branch as INVITE ? If so, this is really not SIP-compliant. I am not sure we are able to handle that but we'll have a look.
Could you post the call-flow to be sure we have all the details ?

Regards,

Thomas

[Ilya Korolev]

Yes, callflow is simple:
INVITE-200-ACK, and ACK has the same branch as in INVITE

If it's impossible to change cipango behaviour - it's ok, we'll fix it in sip client

24.08.2011, 16:48, "Thomas" <tho...@cipango.org>:

[Thomas]

Yes, it would be much better if you are able to fix it in the SIP client since this is a non-compliant behavior. It would be easier for you as well since this invalid ACK would be an interoperability issue with most SIP elements.
If it is easier for you, cipango supports ACK (for 200) with branch=0. There are a few SIP elements sending this kind of ACKs (since branch for ACK/200 is not as important as for other transactions, this works even if it is not strictly 3261 compliant).

Regards,

Thomas