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)? 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... 3. What should do our proxy (drop 200 OK, using htable try to repair R-URI in ACK or Contact in 200 OK etc.)? 4. ???
Any suggestion is very appreciated :-)
Best regards,
kokoska.rokoska
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:
- Is it valid Contact (without user part)?
Yes, 100% valid.
- 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.
- 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.
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?
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:
- Is it valid Contact (without user part)?
Yes, 100% valid.
- 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.
- 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@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
-
Iñaki Baz Castillo -
kokoska rokoska