Alex,
I will have a go at answering this but will probably also get it wrong - I think there may be some confusion with the terminology. Responses inline
Regards,
Wayne.
Alex said:
I have confused myself and am hoping someone can unconfuse me.
Take a situation like this
/--------- B
A ------- P
\--------- C
A is a UA initiating a call to a URI through P, which is a transaction
stateful proxy. P forks the call (let's say sequentially to B then C). P
also adds "Record-Route".
Let us presume B is unavailable/busy/whatever so P then tries C, which
OK's, and a dialogue is initiated between A and C, with the signalling
still going via P due to the record route. Ok so it used a location service to find the location of these end points (it may be a registrar / location server itself), this will come up later.
How is this meant to work where P is transaction stateful but not dialog
stateful? Specifically, what header fields supplied by A is P meant to
process to ensure that future in-dialog transactions (such as BYE) are
routed to C in the first instance and not B? Or, moreover, assuming the
identification of C as a target was from ephemeral data (perhaps B has
changed his call divert settings whilst the call is still in progress) how
is P then meant to route dialog messages to C at all? I am unsure of a Proxy that is 'transaction stateful' but not 'dialog stateful', if the Proxy isn't stateful -which I believe normally implies for the duration of the 'call' and not per transaction it won't bother adding or noting any headers for stateful purposes. Given your scenarion the location service has provided two contacts for whom the A party was calling (B&C) if B responds with a Busy, the Proxy will try C and forward the best (lowest) response code back to A. If A receives the response from C it will use the SIP Contact header field for return signalling, bypassing this Proxy unless it inserted a Via or record route.
If a BYE is sent for the call between A and C this is a new transaction and dialog, it will rely again on the location service to find the called party - if B and C are again returned and the proxy tries both of these in turn the B party will return a 481 Transacation Does Not Exist, C will return the 200 OK and the call will close down successfully. If the called party changes their profile / call divert etc settings this will update the location server which will return these new values when next queried.
I am in doubt over how you have described what the proxy is and isn't stateful for - I have in my head two basic types of Proxy, Stateful where it records transactions against Call-Id's (for the duration of the call)and non-Stateful where it is just forwarding and not keeping any state information (of course there is also recursive and non-recursive which is not applicable / mentioned for above scenario).
Should it be recording the information as a parameter in the record-route
header (as per 4 of 16.6 of RFC3261 to store state effectively in the
dialog message rather than on the proxy)? Should it rely on B or C
inserting a Contact: header and use that if there are no further Route:
headers? Have I missed the point entirely (I expect so)? What's the
easiest / recommended way to do this?
Alex
******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately.
Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.
******************************************************************************
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
