Iñaki Baz Castillo napsal(a):
El Domingo, 11 de Octubre de 2009, kokoska rokoska
escribió:
Hello,
I have a little bit off-topic question, but - may be - someone could
give me an advice :-)
One of our users, when replying to INVITE, sends in 200 OK Contact
header without user part:
SIP/2.0 200 OK
CSeq: 102 INVITE
Contact: <sip:1.2.3.4:1234>
...
instead of:
SIP/2.0 200 OK
CSeq: 102 INVITE
Contact: <sip:user@1.2.3.4:1234>
...
and it fools our SIP<->ISUP GW and it generates completely strange R-URI
in ACK :-(
My questions are:
1. Is it valid Contact (without user part)?
Yes, 100% valid.
2. What SIP<->ISUP GW should do (mirror
Contact without user part to
R-URI in ACK, reject/drop 200 OK etc.)? May be I can ask them to change
behaviour...
It's a correct behavior.
3. What should do our proxy (drop 200 OK, using
htable try to repair
R-URI in ACK or Contact in 200 OK etc.)?
Nothing.
Any suggestion is very appreciated :-)
Your UAC is broken as it should accept a Contact without username.
Thank you very much, Inaki, for your valuable help!
I really appericiate your explanation - my thoughts were very similar,
but I have to be sure what is correct :-)
PS: Note that "Contact" must be understood by the UA which generated it. This
is, the gateway created that Contact without username so when it receives an
in-dialog request (i.e. ACK for 200, BYE, REFER, re-INVITE...) it must
recognize it, and for sure it does it (as it has stored the information about
dialog (from useri, to uri, request uri, remote contact, local contact,
From/To tags, Call-ID...).
What kind of malformed Contact header is your UA generating upon receipt of a
Contact with no username?
The worst thing is it is not "my" UA - I'm just using it like
SIP<->ISUP
GW. So I have to ask manufacturer to "repair" it :-)
Back to your question: when this UA receives Contact without user-part
it genereates ACK (using some kind of internal magic :-) with R-URI like:
called_number(a)ip.of.my.proxy
so ACK loops infinitely (well, just 69 times :-) through the proxy...
Thanks once more, Inaki, for your explanation!
Best regards,
kokoska.rokoska