Sipdroid's Blog

SIPBroker

Posted in sip by sipdroid on January 12, 2010

1)PSTN Access number listed at:   SIPBroker – PSTN Numbers

 

2)SIP Service providers  list at SIPBroker – Provider White Pages

 

3)for instance,  you have a SIP  account at iptel.org , that should also has has alias xxxxxx@iptel.org  where xxxxxx is a 6 digits number.

According to the list in 2) ,   *478    iptel.org      Iptel  United States [Home]

 

suppose you want somebody who only has PSTN phone to reach you,  then you need to look for an access number listed in 1) that is close to he/she so he/she can avoid long distance call.or a phone access number listed in 1) that services your city if long distance charge is not one concern. for example ,

Boston, MA  +1-617-399-8298 

 

after he/she dials that number, there is voice prompt he/she should then dial *478xxxxxx, where xxxxxx is got from step 3).

SRV and NAPTR

Posted in sip, SRV by sipdroid on November 28, 2009

Sample SRV and NAPTR


bigu.edu IN SOA ns.bigu.edu. root.bigu.edu. (
          2003032001
          10800
          3600
          604800
          86400 )

bigu.edu.             43200 IN NS      ns.bigu.edu.
;
ns.bigu.edu.          43200 IN A       10.0.0.20
sipserver1.bigu.edu.  43200 IN A       10.0.0.21
sipserver2.bigu.edu.  43200 IN A       10.0.0.22
;
_sip._udp.bigu.edu.   43200 IN SRV 0 0 5060  sipserver1.bigu.edu.
_sip._udp.bigu.edu.   43200 IN SRV 1 0 5060  sipserver2.bigu.edu.
_sip._tcp.bigu.edu.   43200 IN SRV 0 4 5060  sipserver1.bigu.edu.
_sip._tcp.bigu.edu.   43200 IN SRV 0 2 5060  sipserver2.bigu.edu.
_sips._tcp.bigu.edu.  43200 IN SRV 0 0 5060  sipserver1.bigu.edu.
_sips._tcp.bigu.edu.  43200 IN SRV 0 0 5060  sipserver2.bigu.edu.
;
bigu.edu. IN NAPTR 0 0 "s" "SIPS+D2T" "" _sips._tcp.bigu.edu.
bigu.edu. IN NAPTR 1 0 "s" "SIP+D2T"  "" _sip._tcp.bigu.edu.
bigu.edu. IN NAPTR 2 0 "s" "SIP+D2U"  "" _sip._udp.bigu.edu.

NAPTR records are not necessary but if they are present RFC3263 mandates at least three records. It further states that they should be listed in this precedence: 1) SIPS+D2T, 2) SIP+D2T and SIP+D2U. In common English this means that TLS over TCP should be used if the calling party has the capability. Failing that TCP should be used and UDP is permitted only as a last resort to keep the call from failing.

In practice BIND implementations are often smart enough to return the SRV records in the target field and the A records to which they point among the glue data so that additional DNS lookups are not required. (how is the return looked like?, I need a sample)

In terms of call flow then a SIP User Agent Client first sends a DNS NAPTR request to the domain specified in the Request-URI. If valid records are returned an appropriate transport is identified. Depending on the richness of the glue data in the first request, a second request is sent to the value in the substitution field.

If no NAPTR records are returned, a DNS SRV request is sent based on the transport preferred by the UAC. IF valid records are returned, the request is sent to the preferred proxy.

As a last resort if no SRV records are found a DNS A record request is sent for the domain in the Request-URI. In the case of sip:alice.smith@bigu.edu the request would be for the IP address of bigu.edu. If a valid IP address is returned, the request is sent to that address using UDP.

The best practice for sites wanting just to get started may be to implement SRV records but not NAPTR records. Those wishing complete detailed information on service location are referred to RFCs 2782, 3263 and 3403.

Format of SRV

"_Service._Proto.Name TTL Class SRV Priority Weight Port Target"

Format of NAPTR

"domain-name TTL Class NAPTR order preference flags service regexp target"