[Asterisk-Users] New Asterisk bounty: SIP simultaneous

[Girish Gopinath]

Excellent Post! Very Informative. Thanks a lot Sir!

Regards, Girish

>From: "Olle E. Johansson" <oej at edvina.net>
>Subject: Re: [Asterisk-Users] New Asterisk bounty: SIP simultaneous
>Date: Mon, 12 Jul 2004 10:52:33 +0200
>
>Paul Mahler wrote:
>
>>Well, this is certainly getting exciting.
>Yes, it is. Sorry for coming in late to this debate...
>
>>Andy, I took your advice and re-read the RFP.
>It's actually RFC, not RFP. (teasing :-)
>
>  > So, gentlemen, help me out here. The spec says:
>>
>>"The Address of record is the "SIP address that the registry knows the
>>registrand. .  .""
>
>The Address of record is the public SIP uri you want people to call you at,
>regardless of the address of the phone you are answering on. It's the
>SIP phone address you place on your business card.
>
>>"A client uses the REGISTER method to register the address listed in the 
>>TO
>>header field with a SIP Server."
>
>A client registers a temporary address, the address to a SIP UA, to the
>SIP registrar that is responsible for the domain in the AOR. This tells
>the SIP registrar (or "location server") where to find you if someone
>calls your URI.
>
>When sending mail, I am not addressing the mail to the IP address you
>are reading the mail on, I am using your public e-mail address that is 
>mapped
>to an e-mail server that is responsible for all e-mail to your domain.
>Later on, you fetch the e-mail from an e-mail client somewhere, with an
>IP address that propably changes as you travel around signing books  ;-)
>
>SIP works the same way. You have a public address and a SIP proxy being
>responsible for keeping track of where you want to answer your calls.
>You can surely register several phones that you want to answer on.
>The proxy takes care of hiding this to the callee, so that the caller
>only get one set of responses. That's what the "forking" stuff is all 
>about.
>If one phone is busy and the other one is answering, we should only signal
>"200 OK" in SIP lingo to the caller.
>
>>I don't see how two different clients can register with a server as the 
>>same
>>address of record. Doesn't the second registration from a new client 
>>change
>>the address of record for the registered client?
>
>You have one address-of-record that maps into several SIP URIs, one for 
>each
>device. These are not as long-term as your a-o-r SIP URI.
>From the RFC:
>
>"Location Service: A location service is used by a SIP redirect or proxy 
>server
>to obtain information about a callee’s possible location(s). It contains a
>list of bindings of address-of-record keys to zero or more
>contact addresses. The bindings can be created and removed in many ways;
>this specification defines a REGISTER method that updates the bindings."
>
>>If the second client is trying the same registration as the first client,
>>and it's the responsibility of the client to provide the complete list of
>>bindings, how does the second client know the list of bindings for the 
>>first
>>client that bound the registration?
>
>It's *not* the responsibility of the *client* to provide a list, it's the
>server that responds with a list, telling the client "by the way, these
>devices are also registred for the same a-o-r."
>
>>So isn't this the problem * has? The first client registers as the address
>>of record, then the second client comes in with the same registration and
>>becomes the address of record?
>
>The address of record does not change because of a registration. The stored
>address (the contact: header) of where we can reach you (location) changes.
>And yes,  if you have multiple devices registering for the same Asterisk 
>sip [peer]
>account, it will be changing for each registration. This is not the 
>behaviour
>of most SIP Proxys.
>
>Asterisk is *not* a SIP proxy. It's a SIP registrar and location server.
>It's a very clever SIP UA. It wants to be in the middle of the call
>and wants to be in control of each device. This device-slave view doesn't
>match the SIP architecture. Due to Asterisk's multi-protocol architecture
>we have to make some compromises in the SIP channel to be able to have
>some kind of generic view of calls and phones in the core.
>
>A SIP proxy is never the end point of a call, it should never handle
>the media stream. The power is in the edge, in the phones. This is why
>transfers and other PBX functions is a bit messy with SIP and Asterisk,
>we are trying to find a way to do it centralized as Asterisk but de-
>centralized as SIP...
>
>I've spent a considerable amount of time investigating support for multiple
>registrations on one Asterisk sip [peer] account and after learning about
>Asterisk's architecture come to the conclusion that it is not an easy or 
>even a
>desirable feature to implement. The architecture of Asterisk is a PBX, and 
>the dial
>plan and a lot of apps wants to be in control of the device.
>
>It may be possible, but will probably lead to a lot of changes to Asterisk,
>both core and applications, that no other channel will benefit from. A 
>quick
>hack to support it may lead to a lot of confusion on how to handle other 
>apps.
>And it's a lot more work than the bounty will cover. I suggest that you use 
>a
>forking SIP proxy in conjunction with Asterisk to get this functionality.
>
>If you are looking for a SIP PBX, check Pingtel's Open Source software.
>If you are looking for a SIP proxy, test SIP Express Router from iptel.org.
>If you are looking for a brilliant multi-protocol open source PBX with SIP 
>support,
>stay with Asterisk :-)
>
>Executive summary of a long posting:
>* Yes, SIP supports multiple registrations on one SIP account
>* No, I do not think Asterisk should support this with the current
>   architecture and
>* No, there's no quick fix for a 100 USD bounty
>
>Asterisk is a very large telephony platform, covering many areas and 
>protocols. Very
>few people can know all the details of all the protocols and interfaces we 
>support.
>I don't know much either on H.323 or PRI signalling...
>
>I don't think we should let these misunderstandings judge the quality of 
>Paul's
>Asterisk book. Even authors need to learn now and then :-)
>
>/O

_________________________________________________________________
Planning to travel? Team up with the best. http://www.msn.co.in/travel For 
the best vacation ever!