> I've run into a case (XX-6909) where we aren't handling maddr > parameters > well enough for a call to succeed. In this case, OCS receives a call > and sends a 200 using this Contact URI: > <sip:comm:49171;transport=Tcp;maddr=192.168.3.47>. The 200 goes to the > caller via sipXbridge, and the caller sends an ACK. When sipXbridge > processes the ACK, it composes the request-URI for the ACK that it will > send as <sip:comm:49171;transport=Tcp>. sipXbridge appears to do this > because it knows that sipXproxy does not handle maddr parameters > correctly. Unfortunately, the host-part "comm" does not appear to > route > to OCS, so OCS does not see the ACK, which ultimately causes the call > to > fail. > > There are a number of ways that we could make this situation work, I > think, but it does look like we'll need to support maddr in this > situation if we want to use OCS as a voicemail system. > > Dale >
Just curious why the calls are routing through sipXbridge? I know when we did the old Exchange integration it was with the proxy directly. Should sipXbridge even be involved? > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
