[Spce-user] SIP ACK with changed Contact Header

Wed Feb 4 10:33:03 EST 2015

This involved maddr parameter!
is that a Lync ?
maddr is a very old and deprecated method....

I will try to have a look at this, but currentlry we don't support "maddr".

Daniel

On 02/04/2015 04:27 PM, Marc Storck wrote:
> Hey Daniel,
> 
> this is some argumentation I received back. I’m not into this specific contact header from a low-level protocol side of things:
> 
> Evnetually you can tell me where he might be wrong:
> 
> The argumentation below that we need to recuperate the contact header makes no sense on SIP RFC basis.
> 
> Please have a look at the wireshark packet with as filter
> sip.Call-ID == "SEC11-664a8c0-1764a8c0-1-ko4L04QVg0Kw"
> 
> On the WAN side the SBC makes an outgoing call to the provider.
> So the SBC WAN (178.251.165.238) is the SIP UAC (Sip User Agent Client).
> 
> The provider (46.29.177.34) is the SIP UAS (Sip User Agent Server).
> 
> They start a SIP dialog.
> Please have a look at Wireshark packet 13.
> Here you will see the initial SIP INVITE message from SBC WAN (SIP UAC) to the provider (SIP UAS).
> Here you can find as contact header of our SBC :
> Contact: <sip:35234686621 at 178.251.165.238:5060;transport=udp;maddr=178.251.165.238>
> 
> Which is a correct formatted contact header with the correct information inside.
> 
> Then in wireshark packet 17 and 24, the provider answers with a 183 SIP Session Progress and a SIP 200 OK message.
> In these SIP messages the provider does sent his own SIP contact header of course.
> (he formats this contact header himself of course, he does not use ours, since this makes no sense).
> In the wireshark packet 17 and 24 received from the provider, you can read as contact header :
> Contact: <sip:ngcp-lb at 46.29.177.34:5060;ngcpct=7369703a3230332e302e3131332e3131333a353038303b707278726f7574653d31>
> 
> So far so good.
> 
> In wireshark packet 27 the SBC WAN responds on the SIP 200 OK with a SIP ACK message.
> Of course, we use our own contact header as always,
> So we do send
> Contact: <sip:35234686621 at 178.251.165.238:5060;transport=udp;maddr=178.251.165.238>
> As we also already did send in previous wireshark packet 13
> 
> Still so far so good.
> This is normal SIP RFC behavior.
> 
> In case they can indicate me in which paragraph of which RFC is started that you do need to recuperate the SIP contact header of another party (and thus not using your own contact header),
> They can pass me the exact details of the SIP paragraph number,
> Since this would be totally new…
> 
> I give already some RFC 3261 text that confirms my statement ta the start of my mail :
> 
> Some examples
> RFC3261 states :
>    Contact contains a SIP or SIPS URI that represents a direct route to
>    contact Alice, usually composed of a username at a fully qualified
>    domain name (FQDN)
> the contact header must contain a direct route to YOURSELF.
> 
> the Contact header field tells other elements where to send
>    future requests.
> If you would recuperate the contact header of the remote side, this means that future requests will be sent from the remote side to the remote side (himself this), which is totally unwanted.
> 
> This occurs because the endpoints
>    have learned each other's address from the Contact header fields
>    through the INVITE/200 (OK) exchange, which was not known when the
>    initial INVITE was sent.
> Each side has his OWN, DIFFERENT contact header, where he can receive SIP messages.
> I also already explained this at the start of my mail.
> 8.1.1.8 Contact
>    The Contact header field provides a SIP or SIPS URI that can be used
>    to contact that specific instance of the UA for subsequent requests.
>    The Contact header field MUST be present and contain exactly one SIP
>    or SIPS URI in any request that can result in the establishment of a
>    dialog.  For the methods defined in this specification, that includes
>    only the INVITE request.  For these requests, the scope of the
>    Contact is global.  That is, the Contact header field value contains
>    the URI at which the UA would like to receive requests, and this URI
>    MUST be valid even if used in subsequent requests outside of any
>    dialogs.
> 
> 
> Regards,
> 
> Marc
> 
>> On 04 Feb 2015, at 16:19, Daniel Grotti <dgrotti at sipwise.com> wrote:
>>
>> 12.1.1 UAS behavior
>>
>>   When a UAS responds to a request with a response that establishes a
>>   dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
>>   header field values from the request into the response (including the
>>   URIs, URI parameters, and any Record-Route header field parameters,
>>   whether they are known or unknown to the UAS) and MUST maintain the
>>   order of those values.  The UAS MUST add a Contact header field to
>>   the response.  The Contact header field contains an address where the
>>   UAS would like to be contacted for subsequent requests in the dialog
>>   (which includes the ACK for a 2xx response in the case of an INVITE).
>>
>>
>>
>> Please note:
>>
>> "The UAS MUST add a Contact header field to
>>   the response.The Contact header field contains an address where the
>>   UAS would like to be contacted for subsequent requests in the dialog
>>   (which includes the ACK for a 2xx response in the case of an INVITE)."
>>
>>
>> Daniel
>>
>>
>> On 02/04/2015 03:36 PM, Marc Storck wrote:
>>> Hello,
>>>
>>> can anybody point me to the RFC that requires the SIP ACK to contain the identical Contact Header from the SIP 200 OK.
>>>
>>> (SPCE ignores the SIP ACK and drops the call after 32 seconds, if contact header in SIP ACK differs from the one in SIP 200 OK).
>>>
>>> Thanks for the help.
>>>
>>> Regards,
>>>
>>> Marc
>>>
>>>
>>>
>>> _______________________________________________
>>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com
>>> https://lists.sipwise.com/listinfo/spce-user
>>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> https://lists.sipwise.com/listinfo/spce-user
> 