----- Original Message ----- From: Jerry To: Sip Shakers Cc: SIP-Implementors Mailing-List Sent: Tuesday, July 19, 2005 2:45 PM Subject: Re: [Sip-implementors] Multiple applications using a single SIP UA
See inline ----- Original Message ----- From: "Sip Shakers" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, July 19, 2005 11:25 AM Subject: Re: [Sip-implementors] Multiple applications using a single SIP UA > thanks for all replies...i think i am getting some clues > let me just put more clarity > > 1. i would like to use only one AOR (sip or sips)... for all kind of > SIP services > > 2. there is only one instance of sip stack and one generic UA which is > required to route each incoming request to an appropriate application > running over it in the user-device. And only UA does the common > registration using AOR and bindng with dynamically allocated IP > address as contact. > > 3. There are multiple applications which are using single instance of > UA and sip stack. > > for the example sake assume 3 application > A. Push-to-x and VoIP app > B. Messenger with Session-based messaging support using MSRP > C. An interactive game > > All 3 apps can expect INVITE request for their corresponding session. > And the remote party who is sending an INVITE can send it for any of > the 3 types of sessions. > > Scenario 1. > UA doesn't use a unique user part for each function/application during > registration (as Paul suggested). Hence there is only one contact in > the location server. > > So UA will receive INVITE with a Request-URI which is the contact > registered. Now how does UA route this request to appropriate > application? > > My Guess - it is not possible unless some std parameter is used for > std service indication in a particular sip header. And this has to be > filled by caller. Same std parameter will be used by applications to > register locally with UA in a device. > > Personally i am looking for this solution. > > Advantage - This way intelligence is with clients rather than servers. > Solution becomes more flexible. > [Jerry] An example of how service-dependent-routing can be done is the 3GPP IMS framework where we have filter-criteria for routing requests to specific application servers. How the request should be routed is contained in an Accept-Contact header as a service-specific feature-tag which indicates which *service* this request should be routed to. A *service* can *register* with the application management framework, a filter criteria specifying the conditions for application-specific request routing to it. Alternatively, the filter criteria can be provisioned. If you are to do this outside the IMS framework, then I guess it would be proprietary. May be adaptation is possible. :) > Scenario 2. > UA may use different user part for each type of application during > registration. But these user parts are not public. Caller still has to > use AOR. > > Issue - then how does server on receiving the request selects the > appropriate contact and use that as Request-URI such that on receiving > the request UA can route the request properly to the application? > > Can i use RFC 3840 (Indicating User Agent Capabilities in SIP) here in > scenario 2? If yes then what is the role of server and UAC/UAS? I > guess RFC does not clearly define that. > > RFC 3841 (Caller Preferences) gives some mechanism to select from > different contacts. But couldn't find exactly how different types of > services can be incorporated. There has to be a field which can filled > with any text and only callee and caller should understand that. And > this field can act as an application or service type parameter. > > regards, > -nins > > >
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
