484 seems to me, a very bad way of doing overlapped dialling in SIP.
rfc 3578 (http://www.ietf.org/rfc/rfc3578.txt) says:
Routing in SIP can be controlled by the administrator of the network.
Therefore, a gateway can be configured to generate SIP overlap
signalling in the way described below only if the SIP routing
infrastructure ensures that INVITEs will only reach one gateway.
What if you are using something like DNS SRV to route to a group
of gateways? How can one ensure all new requests go the same gateway?
RFC 3578 then says
When the routing infrastructure is not under the control of the
administrator of the gateway, the procedures of Section 2 have to be
used instead.
The problem is that section 2 talks about "Waiting for the Minimum
Amount of Digits"
but this is not very useful - effectively it stops you using overlap
dialling.
Now, the RFC discourages use of the route learnt in 484:
Note that it is possible to receive a response to the first INVITE
before having sent the second INVITE. In this case, the response
received would contain a To tag and information (Record-Route and
Contact) to build a Route header field. The new INVITE to be sent
(containing new digits) should not use any of these headers. That
is, the new INVITE does not contain neither To tag nor Route
header field. This way, this new INVITE can be routed dynamically
by the network providing services.
But, again, what it you want to route to the same PSTN gateway?
later the RFC says:
3.5. SIP to ISUP
In this scenario (the call originates in the SIP network), the
gateway receives multiple INVITEs that have the same Call-ID but have
different Request-URIs. Upon reception of the first INVITE, the
gateway generates an IAM following the procedures described in RFC
3398 [3].
When a gateway receives a subsequent INVITE with the same Call-ID and
From tag as the previous one, and an updated Request-URI, a SAM
should be generated as opposed to a new IAM. Upon reception of a
subsequent INVITE, the INVITE received previously is answered with
484 Address Incomplete.
For me, this is very problematic. It prevents learning of the route
anyway.
So while one section says you shouldn't use the route, this "SIP to
ISUP"
section encourages behaviour that completely prevents learning of the
route.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
