Dienstag, 14. Februar 2012 11:16
We are trying to implement dialog-recovery at our endpoint when communicating with lync server.
On receiving 430 flow failed for an UPDATE after long duartion with wait-for-session-update , do we need to send a full registration after session timer timeout or an empty UPDATE only with no route set after session timer timeoutWhat is the significance of this?
As per MS-SIPRE server is supposed to send 200ok to update with no route set with the new record-route .
Is my understanding correct?
Is it necessary for both the endpoints to support dialog recovery to maintain the call session?
Are we doing anything wrong here.
Any suggestions or pointers will be of great help.
Dienstag, 14. Februar 2012 16:00Moderator
Thank you for your queston regarding MS-SIPRE. One of our engineers will follow-up with you soon.
Dienstag, 14. Februar 2012 17:43Moderator
I will look into this and get back to you shortly. Just for the forum, this is in reference to [MS-SIPRE] section 184.108.40.206.1 Processing 430 (Flow Failed) Responses and you are asking if you need to do a full registration upon session timeout after receiving the 430 Flow Failed response. Please correct me if I've misunderstood your question.
Microsoft Open Specifications
Mittwoch, 15. Februar 2012 05:02
Thanks for your reply.
We are able to perform dialog recovery with full registration.
Can you please let me know the significance of 'ms-route-sig' and 'ms-received-cid' .
I have seen in lync logs that the value of 'ms-route-sig' is different for each mid dialog requests.
Is it like lync is updating the route set for all update transcations(session refresh) which contain 'ms-route-sig'.
Mittwoch, 15. Februar 2012 05:46Moderator
I'll look into this and get back to you.
Freitag, 17. Februar 2012 09:38
Can i get info on ' ms-route-sig' and 'ms-received-cid' and whether lync is updating their values from each response in the route set?
Freitag, 17. Februar 2012 17:55Moderator
I'm still looking into it.
Montag, 5. März 2012 15:23Moderator
Thanks for your patience. Regarding your first question: according to MS-SIPRE, section 220.127.116.11.4 Dialog Recovery Procedure
"If the target refresh fails with a 430 Flow Failed response that carries a P-Dialog-Recovery-Action header field with a single Wait-For-Session-Update tag as its value, the user agent SHOULD start or reset the recovery refresh timer with the interval set to at least the interval it negotiated for the session timer." It is expected that during this timer interval the other side will send the appropriate dialog refresh message that would enable the User Agent to update its route set. It is not expected that both endpoints support Dialog Recovery mechanism, only that both of them support session timer mechanism as described in [RFC4028].
Regarding "ms-route-sig" and "ms-received-cid", we don't document algorithms for these. They are inserted by the server for its own consumption and are not interpreted by the client. We do provide the following for informational purposes only:
MS-SIPRE, Section 2.2.1 SIP URI Parameter Extensions
ms-received-cid-param = "ms-received-cid=" pvalue
ms-route-sig-param = "ms-route-sig=" pvalue
3.5.1 Abstract Data Model
[RFC3261] section 18 specifies that the transport layer of every SIP element is responsible for managing persistent connections over the Transmission Control Protocol (TCP) and other connection-oriented transport protocols and then index them based on the tuple formed from transport address, port, and protocol of the far end of the connection. Far end is defined in [RFC3261] section 18 as the destination for connections opened by the transport layer and as a source for connections accepted by the transport layer.
If a TCP connection accepted by the transport layer traverses a NAT device, the address and port in the tuple of the far end of the connection belong to the NAT device, and not to the user agent. If the original user agent disconnects for any reason, and another user agent is allocated the same address and port, the transport layer of the SIP element cannot distinguish the new user agent from the old user agent. To avoid misidentifying the connection, the transport layer of the SIP element can maintain a counter that gets incremented with each created connection, and can make this counter a part of the tuple that indexes connections. The counter is of sufficient length that it does not wrap around before the end of the lifetime of all transactions, dialogs, and SIP location service records that were created based on the messages that had the value identifying the connection populated into their header fields.
18.104.22.168 SIP Server (Proxy, Registrar) Operation
ms-received-cid parameter value, defined in section 2.2.5, to save unique connection identifiers, which are values that uniquely identify the connection on which the message was received among all other connections that were or could in the future be established by the server (2) with the same tuple (address, port, and transport. The server (2) can populate ms-received-cid with the value of the counter described in section 3.5.1.
22.214.171.124 SIP Proxy Operation
If the SIPproxy uses a Hash-based Message Authentication Code (HMAC) algorithm, as described in [FIPS198a], to protect the integrity of the Record-Route, Contact, or Via headers and it periodically changes the key used in the HMAC computation, as recommended by [FIPS198a], or if it uses a similar algorithm that depends on periodically updated keys, the proxy MUST start a timer per key when the key is last used to compute the HMAC before it gets changed and it MUST retain the key until the timer fires. The timer SHOULD fire no earlier than 1 hour after it is started for keys used to protect information in Via and Record-Routeheader fields that are copied from the request to the response. The timer SHOULD fire no earlier than 8 hours for keys used to protect information in Contact and Record-Route header field URIs that is preserved in the dialog route set and used to populate Route header fields in mid-dialog requests.
126.96.36.199 SIP Proxy Operation
If the SIPproxy uses an HMAC algorithm, as specified in [FIPS198a], to protect the integrity of the Record-Route or Contactheader fields, and it periodically changes the key used in the HMAC computation, as recommended by the [FIPS198a], or if it uses a similar algorithm that depends on periodically updated keys, and it receives a SIP request that contains the HMAC that the SIP proxy previously inserted, and the SIP proxy no longer has the key to compute the HMAC, the SIP proxy SHOULD reject the request with a 481 Call Leg Does Not Exist response.<23> However, if the SIP proxy implements the extensions for dialog state recovery, as described in section 3.7, it SHOULD follow the procedure defined there to send a 430 Flow Failed or a 481 Call Leg Does Not Exist response.<24>
Microsoft Open Specifications
- Als Antwort vorgeschlagen Tom JeboMicrosoft Employee, Moderator Montag, 5. März 2012 15:30
Dienstag, 6. März 2012 10:26
Thanks a lot for the reply!!.It was helpful to me.
Just want to clear some doubts in what you have mentioned above.
So if an endpoint A is in call with B and if A receives 430 flow fail with "wait-for-session-update",
as per your suggestion endpoint A need not start any recovery procedure . Am i right?
So we are assuming endpoint B will perform dialog recovery when the UPDATE which he send receives 430 flow fail right?
But if endpoint B also receives 430 flow fail with "wait-for-session-update" , then both will not perform the recovery mechanisms rite?
Is my understanding correct?
One more doubt i have..Do lync client perform dialog recovery for INFO?If so what is the mechanism they are using?
I didnt see anything related to INFO message in MS-SIPRE.It will be greatful if you can provide me some info on this also.
- Bearbeitet RSmitha Dienstag, 6. März 2012 10:30
Dienstag, 6. März 2012 19:37Moderator
Typically, only one of endpoints in the same dialog A or B receives “wait-for-session-update” recovery action, although the spec does not explicitly prohibit the case where both receive it. If latter happens, the dialog recovery won’t work.
Prior 430 is not required for an UPDATE message to be sent in the dialog. UPDATE (or other mid-dialog messages) can be sent for multiple reasons (such as due to session timer mechanism described in RFC4028).
The dialog recovery procedure is not specific to the UPDATE message (see 188.8.131.52.1 Processing 430 (Flow Failed) Responses):
When a user agent receives a 430 Flow Failed response for a mid-dialog request and the response contains a P-Dialog-Recovery-Action header field, the user agent MUST examine the value of this field to decide if it needs to perform dialog recovery procedures.