[asterisk-dev] Peer matching architecture

[Klaus Darilion]

Olle E. Johansson wrote:
> SIP lovers out there!

I will answer anyway :-)

I'm concerned about the naming ...

I like type=phone, that's self describing.

For registration matching - it is not that easy. You know many ITSP 
require the PBX to register, but they will send the DID in the RURI 
(instead of the registered username) - so this must still be possible to 
use, also with new peer types. (of course this will not allow anymore to 
differentiate between multiple registrations to the same ITSP).

Further, if the Asterisk is behind NAT and the ITSP uses a broken NAT 
traversal which rewrites the contact (in openser terms: 
fix_nated_contact() instead of fix_nated_register), the matching on RURI 
breaks too - although sometimes username and URI paramters survives, 
thus RURI matching could be done on username and a URI parameter.

What about handling everything in a new type called "trunk":
[foobar]
type=trunk	; trunks are used to connect to ITSPs
register=yes    ; most ITSP require you to register
                 ; to their servers. default: no
host=itsp.com   ; Domain of the service provider
username=100456 ; The SIP username given to you by the ITSP (This
                 ; username will be used in the From header of
                 ; outgoing request)
secret=3gndj3   ; The SIP password give to you by your ITSP
; authusername=.... ; Sometimes ITSPs use a dedicated authentication
                     ; username
;inauthusername= ; If you want your service provider to authenticate too
;inauthsecret=   ; specify the authusername and the secret you gave to
                  ; your ITSP
;did=yes        ; Needed if this single registration is used for inbound
                 ; routing of multiple DIDs/extensions. default: no

peer matching works the following way:
register=no  --> plain IP matching (like type=peer)

register=yes
  \ \
   \ -  did=no --> match on incoming RURI (Asterisk generated
    \               username and URI parameter)
     \
      - did=yes --> plain IP matching

regards
Klaus


> I am still afraid of changing the peer matching too much and what it
> could cause. Therefore I suggest the following:
> 
> - We add a new config option "newdevicematching=yes" and make it
> default to "no" for the next release. Then remove it a release after
> that, since it's no longer "new" :-)
> 
> - If it's set to "yes", we add a few new options
> 
> - type=service that implements the callbackexten stuff properly and
> deprecates register=
 > - type=proxy that implements the stuff I have
> with matchrules
> 
> and maybe somewhere in the future - type=trunk that matches on
> domains - type=phone that replaces the user/peer stuff for phones
> (and matches on both username and domain)
> 
> We have most of the code for the first two types and I don't think
> it's hard to get the last two types working properly and get it
> tested.
> 
> This way, we don't mess with the old "peer", "user" and "friend" at
> all. Overloading those with new functions has proven a bad thing
> (like callbackexten). These definitions would still work as expected,
> just don't exist in the sample config any more.
> 
> Feedback?
> 
> /O _______________________________________________ --Bandwidth and
> Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list To UNSUBSCRIBE or update options visit: 
> http://lists.digium.com/mailman/listinfo/asterisk-dev ;        nat =
> no                ; Default. Use rport if the remote side says to use
> it. ;        nat = force_rport       ; Force rport to always be on. ;
> nat = yes               ; Force rport to always be on and perform
> symmetric RTP. ;        nat = comedia           ; Use rport if the
> remote side says to use it and perform symmetric RTP.