[Kamailio-Users] Having Problem routing an ACK
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Aug 25 18:06:16 CEST 2008
As Iñaki said ....
and one more - the is no difference if the routing in the SIP proxy is
done stateless or stateful.
regards
klaus
Stagg Shelton wrote:
> This is exactly what I told the carrier engineer about the problem. The
> contact in the 200 OK is my Asterisk PBX the RURI in the ACK (returning
> from the carrier) is my OpenSER. I informed the carrier that according
> to my interpretation of the RFC 3261 the RURI in the ACK MUST match the
> contact in the 200 OK with SDP.
>
> The carrier interop engineer sent me the following remark after I
> notified them of the issue, and began pressing them on the way their ACK
> was created.
>
> == BEGIN ==
> The Request URI field is used for routing of initial dialog messages.
> If state is not kept in [Open]SER by using the tm module, the SIP
> message can be routed based on the VIA or contact header, or worst case
> follow the same routing rules based on the original Request URIs, just
> like the original INVITE message did.
> == END ==
>
> After some subsequent communication where I again questioned the way in
> which their system creates the ACK. I received the below from them.
>
> == BEGIN ==
> All I was saying is that based on the way your system handles messages
> we send to it, your statement about changing the Request-URIs of ACKs
> based on values from the SDP of the 200 OK is not the case. I believe
> that some systems do however update the ACK’s Request-URI based on the
> Contact header field from the 200 response, but most system’s don’t
> route the ACK based on its Request-URI when keeping state.
>
> I have another question based on our use of SER internally. When we
> send the initial INVITE, the Request-URI is set as the number at (@) the
> address of your [Open]SER proxy. SER will then re-write the request URI
> of the INVITE based on the logic in the local ser.cfg file and any local
> location/alias database entries used in that logic and forward the
> message to the destination, in this case the PBX, while adding a
> Record-Route header with LR set to ensure SER stays in the dialog in
> terms of signaling as well as adding a VIA header with a branch tag used
> to mark the dialog for stateful processing (when the TM module is used).
> In the case of stateful processing, these values are used to maintain
> the same signaling path for subsequent messages within the same dialog.
>
> When stateless routing is used via the SL module, all new requests
> (including an ACK to a 200 response) should follow the same routing
> logic as the initial request. Therefore, when the ACK arrives at your
> SER proxy, the same routing logic should be applied to the ACK as was
> the original INVITE, and it should be forwarded on to the correct
> destination. If this is not the case, then either there must be some
> kind of state being tracked or the logic has been written to handle
> ACKs differently on purpose as this would be the only way that the
> handling and routing (especially the computation of the final
> request-uri) would be different for an ACK from an INVITE.
> == END ==
>
> At this point I am ready to address any issue with my OpenSER
> configuration that can be identified, but if the problem is actually due
> to the ACK not being constructed correctly, I have to take off the
> technical hat, and put on the business hat, and try to get them to look
> at their systems, and push their vendors for support in this issue.
>
> Thank You
> Stagg Shelton
>
>
>
>
> On Aug 25, 2008, at 9:52 AM, Klaus Darilion wrote:
>
>> Hi!
>>
>> AFAIS the client is buggy (or is there a NAT ALG/Firewall between
>> client and SIP proxy?). Compare the Contact header in the 200 OK and
>> the request URI in the ACK. They MUST be the same!!!
>>
>> regards
>> klaus
>>
>>
>> U +0.000315 8.17.32.184:5060 -> 63.209.207.135:5060
>> SIP/2.0 200 OK*
>> Via: SIP/2.0/UDP
>> 63.209.207.135:5060;branch=z9hG4bK-8921-48b022df-dcaa3e6a-2f5ec169*
>> Record-Route: <sip:8.17.32.184;lr=on;did=952.4d684275>*
>> From: Anonymous
>> <sip:restricted at 63.209.207.135>;tag=88cfd13f-13c4-48b022df-dcaa3e6a-b4657f0*
>> To: <sip:+16783832765 at 8.17.32.184:5060>;tag=as40da5b97*
>> Call-ID: ATLMGC0720080823144655027771 at 209.244.63.15
>> <mailto:ATLMGC0720080823144655027771 at 209.244.63.15>*
>> CSeq: 1 INVITE*
>> User-Agent: Asterisk PBX*
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY*
>> Supported: replaces*
>> Contact: <sip:+16783832765 at 8.17.32.19>*
>> Content-Type: application/sdp*
>> Content-Length: 180*
>>
>>
>>
>> U +0.072541 63.209.207.135:5060 -> 8.17.32.184:5060
>> ACK sip:+16783832765 at 8.17.32.184 SIP/2.0*
>> From: Anonymous
>> <sip:restricted at 63.209.207.135>;tag=88cfd13f-13c4-48b022df-dcaa3e6a-b4657f0*
>> To: <sip:+16783832765 at 8.17.32.184:5060>;tag=as40da5b97*
>> Call-ID: ATLMGC0720080823144655027771 at 209.244.63.15
>> <mailto:ATLMGC0720080823144655027771 at 209.244.63.15>*
>> CSeq: 1 ACK*
>> Via: SIP/2.0/UDP
>> 63.209.207.135:5060;branch=z9hG4bK-8922-48b022e5-dcaa5757-3884948f*
>> Max-Forwards: 15*
>> Contact: <sip:restricted at 63.209.207.135:5060;transport=udp>*
>> Route: <sip:8.17.32.184;lr;did=952.4d684275>*
>> Content-Length: 0*
>>
>>
>>
>>
>> Stagg Shelton schrieb:
>>> Thanks again Iñaki. I am attaching siptrace.txt file. I can see
>>> that there appears to be something odd with the ACKs in that they
>>> appear to be sent from my openser back to my openser in a loop until
>>> the max forwards is reached.
>>> ------------------------------------------------------------------------
>>> Thank you for your help.
>>> Stagg Shelton.
>>> On Aug 23, 2008, at 10:08 AM, Iñaki Baz Castillo wrote:
>>>> El Sábado, 23 de Agosto de 2008, Stagg Shelton escribió:
>>>>> Iñaki,
>>>>>
>>>>> Thank you for your response. I have enabled the siptrace module in
>>>>> openser. The data in the mysql table only shows the trace between the
>>>>> carrier and openser. Can I submit a pcap file that shows all of the
>>>>> SIP communication that occured during the call.
>>>>
>>>> Hi, you don't need to enable siptrace. Just install "ngrep" and do:
>>>>
>>>> ngrep -d any -P '*' -W byline -T port 5060
>>>>
>>>>
>>>> --
>>>> Iñaki Baz Castillo
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.kamailio.org <mailto:Users at lists.kamailio.org>
>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.kamailio.org <mailto:Users at lists.kamailio.org>
>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
More information about the sr-users
mailing list