25 Sep
2009
25 Sep
'09
3:49 p.m.
Hello,
On 25.09.2009 17:16 Uhr, Olle E. Johansson wrote:
[...]
RFC 3261, section 10.3:
Registrars MUST ignore the Record-Route header field if it is included
in a REGISTER request. Registrars
MUST NOT include a Record-Route header field in any response to a
REGISTER request.
A registrar might receive a request that traversed a proxy which
treats REGISTER as an unknown request and
which added a Record-Route header field value.
Oops.
in the words of sipwarriors on this list, IETF specs s...ks most of the
time and some implementations even more, so from the other side of the road:
IMWY RFH 3261, section '10.3' says:
Hazard plays an important role in getting SIP rolling, if you can tweak
SIP messages and pray enough, things may work as you need even they
shouldn't happen that way at all.
Glossary:
IMWI - It Must Work Yesterday - the international alliance and
standardization group of management and sales people
RFH - request for hack
:-) Daniel
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
In my scenario kamailio is not a registrar, it's just a proxy
forwarding requests from asterisk to the provider.
I see.
As Juha said, REGISTER does not create a real dialog, since the
contact in 200OK is the address of publisher not of destination. So a
proxy does not have within-dialog like routing information.
So here is a hack you can try:
- add record route on your proxy
- the provider should add its own record route to REGISTER reply --
if it is kamailio, that is simple via append_to_reply() from textops,
just before save() call.
- hope/pray that asterisk is using these dialog info for building
re-registration messages
- on your kamailio route based on Route header