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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
