Subject: [Sip] RPH in responses : alternative GETS flow

From: Jeroen van Bemmel <[email-masked]>
Date: Tue, 20 Nov 2007 22:37:52 +0100

Janet,

Regarding 
http://www.ietf.org/internet-drafts/draft-gunn-sip-req-for-rph-in-responses-00.txt:

Thanks for writing this, it does help a lot to clarify the intended 
usage. However, I believe it does not resolve any of the concerns 
regarding the security issues.

As already identified in your document, an alternative solution is to 
send an UPDATE request in the opposite direction. A potential issue with 
this solution is that UPDATE cannot be sent until the dialog is 
established. So what if the B2BUA AS would simply send an empty 183 
response with 100rel back to the caller (as a status update), in 
parallel with forwarding the INVITE further upstream? Then the caller 
would send a PRACK to confirm, and after the PRACK is OK'ed the B2BUA 
would place SDP2 in an UPDATE request instead of a 183 response. Like so

    A                            GETS AS                             B
    |                                |                                |
    |-----------(1) INVITE SDP1----->|                                |
    |                    Look up in data base for                     |
    |                         priority level (=3)                     |
    |                                |                                |
    |<-(2a) 183 Ses Progress no SDP- |---(2b) INVITE SDP1 RPH wps.3-->|
    |-------------(3) PRACK--------->|                                |
    |<---------(4) 200 OK (PRACK)----|                                |
    |                                |<-(5) 183 Session Progress SDP2-|                      
    |<-(6a) UPDATE RPH wps.3 SDP2----|---(6b) PRACK RPH wps.3---***-->|
    |  ***                           |                          * *   |
    |  * *                           |                          * *   |
    |--*R*---------(7) OK----------->|<--(8) 200 OK (PRACK)-----* *---|
    |  *E*                           |                          *R*   |
    |  *S*                           |                          *E*   |
    |  *E*                           |                          *R*   |
    |  *R*                           |                          *E*   |
    |  *V*                           |                          *R*   |
    |  *A*                           |                          *V*   |
    |  *T*                           |                          *A*   |
    |  *I*                           |                          *T*   |
    |  *O*                           |                          *I*   |
    |  *N*                           |                          *O*   |
    |  ***                           |                          *N*   |
    |  ***                           |                          ***   |
    |  ***                           |                          ***   |
    |---(9) UPDATE SDP3------------->|                                |

It's 2 messages more than your proposed flow, but it allows to authenticate the source of the RPH 
(and provides earlier feedback to the caller, about the successful start of the GETS service) 

Regards,
Jeroen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip