I'll second Scott on this.
Further, those contacts may very in different ways depending on how
coupled or uncoupled the different instances of sip functionality are:
- Each function could obtain its own sip address (from DHCP).
Then the contacts would be separated by address.
(Not a likely case.)
- The device could get the address, but each function is running
its own sip stack. Each gets a separate port to receive on.
Then contacts would all have the same address but different ports.
- The functions share a sip stack implementation but are still
otherwise independent of one another. The address and port will
be the same for all functions using the stack. In this case the
sip stack will have to do the demultiplexing. This can still
happen two ways:
. each function can use a contact with a unique user part.
It must coordinate with the stack implementation for the
assignment of particular user parts to functions. The stack
then dispatches incoming requests to functions based on the
user part of the URI.
. all functions can use the same contact. The stack then must
dispatch requests to functions based on other features of the
request. For instance in IMS the P-Called-Party-ID is used
for this. (Of all the solutions, I find this the ugliest.)
Paul
BTW: who/what are Sip Shakers?
Scott Lawrence wrote:
On Mon, 2005-07-18 at 09:37 +0530, Sip Shakers wrote:
As applicability of SIP increasing, there will be a possibility where
multiple applications within a single end-user device will using SIP
functionality simultaneously.
My doubt if there is only one instance of SIP UA on the device and all
applications are using the same SIP UA then how does UA handles
routing of incoming SIP requests to different applications.
In order for those multiple INVITE requests to have been routed to the
system, there would have had to be some binding of a Contact on that
system with the SIP routing infrastructure - typically a REGISTER that
binds a Contact to some AOR. Since a single system can bind any number
of Contact values, it can use them to also do the binding from the UA to
the application responsible for the it.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
