21 Mar
2007
21 Mar
'07
12:37 p.m.
Hello,
comments inline
On 03/20/2007 09:52 AM, Greger V. Teigre wrote:
I'm not sure that I understand what you mean is
wrong. It would be
easier to follow if you include the ACKs. And non-2xxs, what is exactly
the exchange? A full SIP trace would help...
g-)
Emmanuel Hislen wrote:
> Hi,
>
>
> I've been using SER (0.9.6) as a Proxy doing Loose Routing between 2
> endpoints.
>
>
> If I place a call I can see how the ACK for the 2XX response to the
> INVITE is properly handled (Route header removed, Record-Route inserted).
>
> Now with the call still up, I do a re-INVITE which is rejected with a
> 415. The re-INVITE request sent by UAC contained a Route header, as it
> was an in-dialog request in a record-routed dialog. Now as per RFC3261
> section 17.1.1.3:
>
> If the INVITE request whose response is being acknowledged had Route
> header fields, those header fields MUST appear in the ACK. This is
> to ensure that the ACK can be routed properly through any downstream
> stateless proxies.
>
>
> My UAC complied with the above, but SER seemed to choke on this:
>
> whereas the ACK for 2XX was successfully routed by SER in the original
> INVITE, the ACK for non-2XX (looking exactly the same: same Request
> URI, same IP destination, same Route header, ... different Via branch
> of course) is not handled properly: yes the ACK reaches UAS but it
> still has the Route header in it, and no Record-Route was added. And
> I'm guessing that if there had been another proxy in the Route Set on
> the way to the UAS it would have been bypassed.
just to make some definition clear: Route set is the collection of Route
headers, the Record-route headers are used only to learn the route-set.
So the missing Record-route header does not have any impact of the ACK
routing, however could have an impact of routing the BYE for example in
your case. But the RFC says that the in-dialog requests do not modify
the previously learned route-set:
"12.2 Requests within a Dialog
...
Requests within a dialog MAY contain Record-Route and Contact header
fields. However, these requests do not cause the dialog's route set
to be modified, although they may modify the remote target URI.
Specifically, requests that are not target refresh requests do not
modify the dialog's remote target URI, and requests that are target
refresh requests do. For dialogs that have been established with an
INVITE, the only target refresh request defined is re-INVITE (see
Section 14). Other extensions may define different target refresh
requests for dialogs established in other ways.
Note that an ACK is NOT a target refresh request."
But be careful with modifying the route-set in SER (not with
record-routeing but with modifying the route headers directly)!
More info: http://tracker.iptel.org/browse/SER-212?page=all
Regards,
Miklos
SER traces for ACK-2XX:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 0(13574) ===> Loose Routing logic...
0(13574) parse_headers: flags=-1
0(13574) DEBUG: t_newtran: msg id=89 , global msg id=88 , T on
entrance=0xffffffff
0(13574) parse_headers: flags=-1
0(13574) parse_headers: flags=60
0(13574) t_lookup_request: start searching: hash=41794, isACK=1
0(13574) parse_headers: flags=28
0(13574) DEBUG: t_lookup_request: e2e proxy ACK found
0(13574) parse_headers: flags=4
0(13574) DEBUG: totag for e2e ACK found: 0
0(13574) SER: forwarding ACK statelessly
SER traces for ACK-non-2XX:
0(13574) ===> Loose Routing logic...
0(13574) parse_headers: flags=-1
0(13574) DEBUG: t_newtran: msg id=92 , global msg id=91 , T on
entrance=0xffffffff
0(13574) parse_headers: flags=-1
0(13574) parse_headers: flags=60
0(13574) t_lookup_request: start searching: hash=41807, isACK=1
0(13574) DEBUG: RFC3261 transaction matched, tid=007d7195499e33a1
0(13574) DEBUG: t_lookup_request: transaction found (T=0xb616ae48)
0(13574) DEBUG: cleanup_uac_timers: RETR/FR timers reset
0(13574) DEBUG: add_to_tail_of_timer[2]: 0xb616ae90
0(13574) DEBUG:destroy_avp_list: destroying list (nil)
0(13574) receive_msg: cleaning up
This doesn't seem right, am I missing something here?
Thanks,
Emmanuel.
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers