Hi Roman,
I don't have idea about RFC text for this scenario.
IMO here after restart proxy should create TCP link based on address
in Via header sent-by.
To resolve problem of NAT. Peer should send request with rport
parameter in Via header.
Because if rport parameter is not present in Via header than
response will be send to default port that is 5060 for TCP so NAT may reject
this.
Thanks & Regards,
Ravi Kumar
****************************************************************************
****************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Roman
Shpount
Sent: Friday, June 10, 2011 7:07 AM
To: [email protected]
Subject: [Sip-implementors] Sending TCP response with RFC 5626 after
proxyrestart
I am looking at implementation of RFC 5626 (SIP-OUTBOUND) and wanted to see
what would be a proper scenario for sending responses for requests received
over a flow which got disconnected before the response was sent. Imagine the
following scenario:
1. Client registers and creates two TCP flows to two different edge proxies
2. Client sends an INVITE message to edge proxy 1 which responds with 100
Trying and forwards it through the authoritative proxy to the final
destination
3. Edge proxy 1 restarts and client flow to it is closed
4. Authoritative proxy receives a response, and sends it edge proxy 1 based
on flow
4. Edge proxy 1 receives the final response for the INVITE, but has no way
to forward it to the client, and no way to signal the authoritative proxy
that response needs to be re-routed through other proxy. So, the response
fails even though client has a working flow through edge proxy 2
As far as I understand there is no way to recover from this situation or to
deliver TCP response to a SIP client behind NAT, if the original request
connection is closed.
BTW, it looks like there is a recovery mechanism for sending requests to the
client by addressing them to a GRUU URI and making the authoritative proxy
re-route them over the alternative flow. I am looking for something similar
for responses.
_____________
Roman Shpount
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
