Page 127 - Asterisk™: The Future of Telephony
P. 127

Matching on Username Instead of IP Address
                  Some service providers may insteadSession Initiation Protocol be sending their calls to
                  you via multiple IP addresses, requiring you to create a separate peer account for each
                  IP address. If you don’t know each of these IP addresses, you may need to match on
                  the username instead. The format for the service provider definition needs to only
                  change slightly, but the biggest change to note is that you will need to set the [serv-
                  ice_provider_header] as the username your service provider is going to send the call
                  to. We have also changed the type from a peer to a friend, which from the viewpoint
                  of Asterisk creates both a type user and type peer, where the type user will be matched
                  before the peer:
                   [my_unique_id]
                   type=friend
                   host=10.251.55.100
                   fromuser=my_unique_id
                   secret=my_special_secret
                   context=incoming_calls
                   dtmfmode=rfc2833
                   disallow=all
                   allow=gsm
                   allow=ulaw
                   insecure=invite
                  Note that we’ve removed the deny and permit parameters since we may not know the
                  IP addresses the calls will be coming from. If you do happen to know them and still
                  wish to match them, you can add back in the deny and permit(s) for the IP addresses.


               The fromuser parameter is going to affect the way our INVITE message is structured
               when sending the call to the provider. By setting our username in the fromuser param-
               eter, we will modify the From: and Contact: fields of the INVITE when sending a call
               to the provider. This may be required by the provider if it’s using these fields as part of
               its authentication routine. You can see the places Asterisk modifies the header in the
               next two code blocks.

               Without the fromuser:
                   Audio is at 66.135.99.122 port 18154
                   Adding codec 0x2 (gsm) to SDP
                   Adding codec 0x4 (ulaw) to SDP
                   Adding non-codec 0x1 (telephone-event) to SDP
                   Reliably Transmitting (no NAT) to 10.251.55.100:5060:
                   INVITE sip:15195915119@10.251.55.100 SIP/2.0
                   Via: SIP/2.0/UDP 66.135.99.122:5060;branch=z9hG4bK32469d35;rport
                   From: "asterisk" <sip:asterisk@66.135.99.122>;tag=as4975f3ff
                   To: <sip:15195915119@10.251.55.100>
                   Contact: <sip:asterisk@66.135.99.122>
                   Call-ID: 58e3dfb2584930cd77fe989c00986584@66.135.99.122
                   CSeq: 102 INVITE
                   User-Agent: Asterisk PBX
                   Max-Forwards: 70
                   Date: Fri, 20 Apr 2007 14:59:24 GMT

                                                              Connecting to a SIP Service Provider | 99
   122   123   124   125   126   127   128   129   130   131   132