Kedar Patil wrote:
To me the issue does not seem to be if there is a single or multiple
instances of UA. Pls. consider following argument.
Requirement:
Today a user has many un-unified IDs: email address, mobile number, home
number, work number, fax number, pager number etc.
Although, we all would like to have a single AOR to distribute to our
friends e.g. sip:[EMAIL PROTECTED] A UAC sends all kinds of SIP
communications to this one AOR. Somehow they should be routed to
appropriate application on UAS side.
This is an entirely different question.
They are both reasonable questions to ask - just different ones.
Question:
Is there any SIP header/field that specifies "type of service" contained
in a SIP request? Note that there may not be any message body in the SIP
request. The 'types of services' can be standardized by IANA.
There is no one thing. There are many things that can be used to try to
address this, but in general it is an unsolvable problem.
To a certain extent the method can be used to distingush - e.g. INVITE
vs MESSAGE vs SUBSCRIBE. In the case of SUBSCRIBE, you may need to go
further and consider the event type. (subscribe to presence, subscribe
to MWI, subscribe to 'reg' package, 'dialog' package, 'refer' package.)
This is helpful in certain situations, but not others. Subscribing to
presence and to MWI can often be meaningfully routed this way. Not so
much for other things.
Just forking the request and letting the various endpoints decide if
they want to accept can often work. However this still assumes that
there is something in the request that permits the various endpoints to
decide if they should accept. It can work for INVITE with an offer in
SDP - those that understand at least part of the offer can respond
positively and others can reject. But this doesn't work in the case of
an INVITE without an offer. You might be expecting a response with an
offer of voice, but instead get an offer for MSRP or T.38.
Callerprefs (RFC 3841) is closest to what you seem to be asking for. It
allows the caller to express preferences for the features it would like,
that are matched against capabilities that are advertised by endpoints
when they register with the AOR. However this isn't yet widely implemented.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
